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REMARKS / ARGUMENTS 

In the Office action of January 15, 2009, claims 1-45 were rejected. The applicants 
request amendment of the application as indicated above and withdrawal of the rejection. 

Claims 31-45 stand rejected under 35 U.S.C. 112 as indefinite because the term "said 
second application" in claim 31 lacks an antecedent basis and, since claim 31 is indefinite, 
dependent claims 32-45 are also indefinite. The applicants request amendment of claim 31 as 
indicated above; submit that claim 31 , as amended, is definite; and request withdrawal of the 
rejection of claims 31-45. 

Claims 1-5, 8-10, 12-13, 16-20, 23-25, 27-28, 31-35, 38-40, 42 and 43 stand rejected 
under 35 U.S.C. 103 as unpatentable over Sorrentino et al., U.S. Patent No. 7080060 
(Sorrentino) in view of Veselov, U.S. Patent No. 7131 120 (Veselov). While the Office action 
concedes that Sorrentino does not disclose notifying an application associated with a listener 
when another application causes an event in a shared object, the Office action asserts that 
Sorrentino does teach a listener attached to a shared object and operably associated with a 
second application running in a second machine and "listening for the event" (citing Sorrentino: 
col. 3, line(s) 41-58) and asserts that Veselov teaches "shared object and operably associated 
with a second application running in a second machine and notifying the second application 
when the first application caused the event" (citing Veselov; col. 4, line(s) 44-48; col. 5, line(s) 1- 
21). 

Veselov, col. 5, line(s) 1-21 mentions a listener in connection with communication 
channels that enable communication between "library objects" using an inter-application 
messaging method, such as, the Java Messaging Service (JMS) which, according to Veselov, 
can be used to transmit queries and requests and provides three ways of sending messages. 
The only reference to a "listener" in Veselov is at col. 5, line(s) 6-21 which describes a plurality of 
listeners each receiving, in turn, a respective message until a message has been received by 
each listener, starting a new "round robin cycle." While the listener disclosed by Veselov is 
clearly limited to the "round robin" communication method, the current Office action introduces 
and relies on a new reference, Haase, JAVA MESSAGE SERVICE API TUTORIAL (Haase), for 
teaching that a message listener is also used with the JMS publish and subscribe messaging 
method, which Veselov mentions by name but does not describe (col. 5, line(s) 13-14). 
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According to Haase, the JMS listener monitors a message queue and when a message 
addressed to a subscribing destination arrives in the queue, a JMS provider delivers the 
message by calling a method in the listener (Haase, pg. 19). However, the applicants 
respectfully submit that neither Haase nor Veselov disclose or suggest that the JMS listener of 
Veselov is either stored in the shared object space, attached to a shared object, or listening for 
an event in a shared object, all as recited in the claims. As conceded by the Office action of 
August 24, 2007, page 6; Veselov does not "disclose that a listener is associated with at least 
one of the applications running on a virtual machine that is listening for the event." 

Sorrentino discloses a listener adapted to acknowledge requests for data access from 
one or more system processes or services and to connect the requesting service to a respective 
query thread (Sorrentino, Abstract). In general, the listener of Sorrentino "preferably loops or 
remains in a wait state until it receives a data access request message from an application 
service 212" (Sorrentino: col. 3, line(s) 33-35). The listener may establish communication with 
the requesting service, preferably endeavors to assign one of the query threads for the 
requesting service, and then returns to the wait state where it awaits additional requests 
(Sorrentino: col. 3, line(s) 41-60) but, contrary to the Office action, Sorrentino, including the 
portion relied on in the Office action, does not disclose or suggest that the listener is listening for 
the occurrence of an event in a shared object that is caused by an application not associated 
with the listener. Nothing in Sorrentino suggests that the listener is monitoring or can monitor a 
shared object for the occurrence of an event. In addition, the listener of Sorrentino 
communicates only with the requesting application service and there is no suggestion in 
Sorrentino that even if an event was detected that the listener would place a message 
addressed to an application that did not cause the event in a message queue or otherwise notify 
an application of the occurrence of the event unless the application was associated with the 
listener and had requested the event. The applicants submit that neither Sorrentino nor Veselov 
disclose a listener that is operably associated with a first application and attached to a shared 
object that is listening for an event in the shared object that is caused by a second application. 

The Office action asserts that it would have been obvious to incorporate the teaching of 
Veselov into the method of Sorrentino because a person of ordinary skill "would utilize virtual 
machine application to share resources to have a platform independent application execution 
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with shared resources and notify all applications about events messages received in the 
message queue to notify the current state of the system using JMS messaging technology of 
publish and subscribe." However, while virtual machines, platform independent execution, and 
JMS messaging technology are disclosed in Veselov; the later disclosure, Sorrentino, includes 
none of the supposedly motivating features and neither Veselov nor Sorrentino describe or 
utilize the JMS publish and subscribe messaging method. Even if it is assumed that the 
motivation suggested by the Office action is sufficient motivation for combining the teachings of 
Sorrentino and Veselov, the objectives suggested by the Office action could achieved by a 
system in which each of the prior art listeners performs its separate prior art function, but a 
system with two listeners, neither of which is the listener recited in the claims, would not 
anticipate or suggest the claimed system. Therefore, the Office action opines that it would be 
obvious to persons of reasonable skill, motivated by the desire for a virtual machine application, 
to combine the teaching of Sorrentino and Veselov by creating a new listener having a 
combination of attributes not suggested by either Veselov or Sorrentino but identifiable by 
parsing the description of the listener in the application. The applicants respectfully submit that 
there is no teaching or suggestion provided in the prior art of record to create a new listener by 
combining the prior art listeners as suggested by the Office action. In addition, the prior art does 
not suggest a motivation for creating a new listener and a new listener would not be necessary 
and is not suggested by a desire for a virtual machine application as suggested in the Office 
action. Moreover, the experimentation necessary to create of a new listener is contraindicated 
by the suggested motivation to use JMS messaging technology which already includes a listener 
which would be jettisoned with the creation of a new listener. 

The applicants submit that claims 1,16 and 31 are not obvious from the prior art of 
record because neither Veselov nor Sorrentino disclose or suggest a listener that is operably 
associated with a first application and attached to a shared object that is listening for an event in 
the shared object that is caused by a second application and, therefore, a combination of the 
prior art does not disclose or suggest the listener of the claimed system and neither the prior art 
nor the Office action suggest a motivation for creating a new listener having attributes that are 
taught only by the application. The applicants respectfully submit that a listener, as recited in the 
claims, is taught only by the applicants and by parsing the description of the listener recited in 
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the claims to identify features for a new listener, the Office action uses the applicants 1 own 
teaching as the basis for concluding that the applicants' teaching is obvious. The applicants 
request withdrawal of the rejection of claims 1,16 and 31 . 

In addition regarding claims 16 and 31 , the applicants respectfully that neither Sorrentino 
nor Veselov discloses a listener able to identify an application, other than the application with 
which the listener is associated, as the application causing an event in the shared object. The 
Office action asserts that Veselov teaches using the JMS messaging service to communicate 
between multiple applications (col. 5, line(s) 11-17) and the JMS "queue and request having the 
identification of the requester in the request (message) to identify the request and other 
information related to the request and notify other application using publish and subscribe 
communication mechanism" citing Veselov: col. 2, line(s) 24-38; col. 5, line(s) 1-21; and col. 7, 
line(s) 59-67 - col. 8, line(s) 1-7, lines 46-65; FIG. 7, reference 704. Veselov discloses a method 
in which a request, which includes the identity of the application making the request, is 
transmitted by an inter-application communication method, such as JMS, to slave repositories in 
non-requesting applications and copied to those slave repositories. While the message 
delivered by the JMS listener includes the identification of the "requester" of an event in a shared 
object and the portions of Veselov cited by the Office action indicate that the application 
receiving a request in its repository may be able identify the requestor of an event, Veselov, 
col. 5, line(s) 15-21 , says nothing about the listener being able to identify the requestor of an 
event from the message that the listener is distributing. 

The prior Office action asserted that JMS is also capable of delivering messages point to 
point "which is not possible if the listener is not able to identify the application that is requesting 
and the resource that is being requested" and the current Office action opines with regard to the 
JMS message listener that "the identification of the application allows the listener in the JMS 
system to process the request to the specific object or resource request as requested and notify 
all the applications about events messages received in the message queue to notify the current 
state of the system using the JMS messaging technology of publish and subscribe" (Office 
action, page 7). According to Haase, page 17, in the point-to-point messaging method each 
message is addressed to a specific queue and the receiving client extracts messages from the 
queue established to hold the client's messages. Similarly, messages are delivered to a "topic," 
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a queue accessible to a plurality of subscribing applications with the publish and subscribe 
method and a listener may be assigned by a message consumer at a destination application to 
retrieve messages addressed to the destination application from the appropriate queue or topic 
and deliver them to the destination. According to Haase, page 9, in the loosely coupled JMS 
messaging method: 

The sender does not need to know anything about the receiver; nor does the 
receiver need to know anything about the sender. The sender and receiver need 
to know only what message format and what destination to use. 
The Office action does not explain why the listener's knowledge of the requester of an event 
would be required for point-to-point communication, but the applicants respectfully submit that 
the JMS listener, the receiver's agent, needs to know nothing more about the sender than the 
JMS message receiver and, according to Haase, in the JMS messaging method, the JMS 
message receiver does not need to know anything about the sender, and, more particularly, 
does not need to anything about the requester of an event in a shared object. To retrieve a 
message from a designated message queue and deliver it to a destination application, the JMS 
message listener requires only the identity of the destination, which according to Haase, page 
30, is designated in header of the message and which, as recited in the claim, is not the 
requestor of the event. Neither Veselov nor Haase suggests that the listener is processing 
"requests to a specific object or resource" or any other reason for the JMS listener of Veselov to 
retrieve of the identity of the "requestor" of an event from a message. The applicants submit that 
the prior art of record does not disclose or suggest a listener as recited in claims 16 and 31 and 
the claims are not obvious for this further reason. The applicants request withdrawal of the 
rejection. 

Further, with regard to claim 31 , the applicants submit that the prior art does not disclose 
a listener that is able to identify a non-associated application as the application causing an event 
from a header included in the shared object. The Office action asserts that the claim language 
does not clarify "how or which object header holds the information of the application which sends 
the request as there are two different object wherein the object referring to a sub-object that 
holds the actual identification information in the specification." This observation is unclear to the 
applicants because while the Office action refers to sending a request and "two different 
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objects;" claim 31, which is consistent with the specification, paragraph [0097], makes no 
reference a request and recites a single object, the shared object, which includes a header that 
identifies the application causing an event. 

The applicants also admit confusion concerning the examiner's interpretation of "the JMS 
queue as the object that holds the request with the request identifying the application and also 
notifies other applications." While Veselov discloses a shared resource that can be locked to 
one of a plurality of applications, each including a library object (col. 4, line(s) 61-67), it is clear 
from Veselov that the JMS message queue is part of a communication channel between library 
objects and is not a shared resource or object in which an application causes an event. Further, 
there is no indication in Veselov that the JMS message queue is stored in the shared object 
space as recited in claim 31 or that the message queue notifies other applications as asserted in 
the Office action. 

While the "request" of Veselov includes the identity of the requester and an application 
receiving a copy of a request can determine the identity of the requestor of an event from the 
request, nothing in Veselov suggests that this information is included a header of a message 
queue or in the header, as opposed to the body, of a message or that the identity of the 
requestor of an event is accessible to the JMS message listener. According to Haase, section 
3.6.1, pgs. 29-30, the JMS message header includes the identity of the message's destination 
but there is no suggestion that the identity of an application causing an event in a shared object, 
which, as recited in the claim, is not the destination of the message, is included in the message 
header. Moreover, Veselov does not suggest how or why a message listener, extracting a 
message from a message queue and delivering the message to a destination application that 
did not cause the event, would utilize the identity of the application causing the event even if the 
information was available to the listener. The applicants submit that none of Sorrentino, Veselov, 
or Haase teach or suggest a listener that is able to identify an application causing an event in a 
shared object from a header of the shared object and request withdrawal of the rejection of claim 
31 for this further reason. 

With regard to claims 2-5, 8-10, 12, 13, 17-20, 23-25, 32-35, 38-40, 42 and 43, the 
applicants submit that the respective claims are dependent from one of claims 1 , 16 or 31 or a 
claim dependent from one of claims 1 , 16 or 31 and each inherits all of the limitations of the 
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claim(s) from which it respectively depends. Since claims 1,16 and 31 are not obvious from 
Sorrentino and Veselov for the reasons stated above; claims 2-5, 8-10, 12, 13, 17-20, 23-25, 32- 
35, 38-40, 42 and 43 are, likewise, not obvious. The applicants request withdrawal of the 
rejection and the allowance of the claims. 

Claims 6, 7, 21, 22, 36 and 37 stand rejected under 35 U.S.C. 103(a) as unpatentable 
over Sorrentino, in view of Veselov and in view of DeMaster, U.S. Patent No. 6066181 
(DeMaster). Claims 6, 7, 21 , 22, 36 and 37, are dependent from one of claims 1 , 16 or 31 or a 
claim dependent from one of claims 1 , 16 or 31 and each inherits all of the limitations of the 
claim(s) from which it respectively depends. Since claims 1,16 and 31 are not obvious from 
Sorrentino and Veselov for the reasons stated above and since DeMaster does not obviate the 
differences between the claims and Sorrentino and Veselov; dependent claims 6, 7, 21, 22, 36 
and 37 are, likewise, not obvious. The applicants request withdrawal of the rejection and the 
allowance of the claims. 

Claims 11, 14, 15, 26, 29, 30, 41, 44, and 45 stand rejected under 35 U.S.C. 103(a) as 
unpatentable over Sorrentino, in view of Veselov and in view of Barinov et al., U.S. Patent 
Publication No. 2004/0025171 (Barinov). Claims 11, 14, 15, 26, 29, 30, 41, 44, and 45 are 
dependent from one of claims 1 , 1 6 or 31 or a claim dependent from one of claims 1 , 1 6 or 31 
and each inherits all of the limitations of the claim(s) from which it respectively depends. Since 
claims 1,16 and 31 are not obvious from Sorrentino and Veselov for the reasons stated above 
and since Barinov does not obviate the differences between the claims and Sorrentino and 
Veselov; dependent claims 11, 14, 15, 26, 29, 30, 41, 44, and 45 are, likewise, not obvious. The 
applicants request withdrawal of the rejection and the allowance of the claims. 

The applicants respectfully request that a timely Notice of Allowance be issued in this 
case. If the Examiner believes that for any reason direct contact with applicants' attorney would 
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advance the prosecution of this application, the Examiner is invited to telephone the 
undersigned at the number below. 

Respectfully submitted, 
Chernoff, Vilhauer, McClung & Stenzel, L.L.P. 
601 SW Second Avenue, Suite 1600 
Portland, Oregon 97204 

Timothy A. |/ong 

Reg. No. 28876 

Telephone No. (503) 227-5631 
FAX No. (503) 228-4373 
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